アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構

专利摘要:
次のうちの１つまたは複数を含む、アプリケーションアウェアネスを用いて終端間サービス構成を検査する方法：そのアプリケーションに特化したサービスｐｉｎｇパケットが対応するアプリケーションを識別するアプリケーション識別フィールドをもつアプリケーションに特化したサービスｐｉｎｇパケットを構築すること、アプリケーションに特化したサービスｐｉｎｇパケットをネットワーク内の宛先へ転送すること、ネットワークエレメントのネットワークインタフェースでそのアプリケーションに特化したサービスｐｉｎｇパケットが対応するアプリケーションに関する静的構成情報を判定すること、その静的構成情報をそのアプリケーションに特化したサービスｐｉｎｇパケットに挿入すること、そのアプリケーションに特化したサービスｐｉｎｇパケットを含むフローに適用する少なくとも１つのポリシーを判定すること、その少なくとも１つのポリシーをそのアプリケーションに特化したサービスｐｉｎｇパケットに挿入すること、および、ネットワークからそのサービスｐｉｎｇパケットを抽出すること。
公开号:JP2011514067A
申请号:JP2010548240
申请日:2009-02-17
公开日:2011-04-28
发明作者:ドルガノウ，アンドルー；ペレス，アンソニー；モーリン，ステイーブン・エドワード
申请人:アルカテル−ルーセント；
IPC主号:H04L12-56

专利说明:

[0001] 本発明は、概して、ディープパケットインスペクション（ＤＰＩ）を使用するパケットベースの通信に関する。]
背景技術

[0002] ＤＰＩは、その既存の形態では、パケットが検査ポイントを通過するときに、非プロトコルコンプライアンス、ウイルス、スパム、侵入、あるいは、そのパケットが通過することができるかもしくはそれが異なる宛先に経路指定される必要があるかを決定するためのまたは統計情報を収集することを目的とする所定の基準を探索し、パケットのデータおよび／またはヘッダ部分を調べる一種のコンピュータネットワークパケットフィルタリングである。ＤＰＩは、時に、内容的検査または内容的処理と呼ばれることもある。ＤＰＩは、パケットのヘッダ部分をただチェックする浅いパケット検査（通常はただパケット検査と呼ばれる）とは対照的なものである。]
[0003] ＤＰＩデバイスは、ＯＳＩモデルのレイヤ２からレイヤ７までを調べる能力をもつ。これは、ヘッダおよびデータプロトコル構造ならびにメッセージの実ペイロードを含む。ＤＰＩは、ヘッダ情報のみに基づく分類よりもより細かな制御を可能にし、パケットのデータ部分から抽出された情報を含む署名データベースに基づくトラフィックを識別し、分類することになる。]
[0004] 分類されたパケットは、転送、マーク付け／タグ付け（ＱｏＳを参照）、ブロック、速度制限されることができ、またもちろんネットワーク内のレポーティングエージェントに報告されることができる。このようにして、異なる分類のＨＴＴＰエラーは、識別され、分析に送られることができる。多数のＤＰＩデバイスが、（パケット単位の分析よりもむしろ）パケットフローを識別することができ、蓄積されたフロー情報に基づく制御動作を可能にする。]
[0005] ＤＰＩは、ネットワーク分析ツールのように、電話およびケーブル会社が、電子メールから、ウェブサイト、音楽の共用、ビデオおよびソフトウェアのダウンロードまで、ユーザがオンラインで受信している情報のパケットを容易に知ることができるようにする。これは、ケーブル事業者およびＩＳＰが彼らのネットワークを通過するトラフィックに応じて帯域幅を動的に割り当てるために使用する手法である。従って、たとえば、ウェブのブラウジングと対比してＶｏＩＰコールにより高い優先度が割り当てられることができる。]
[0006] ＤＰＩは、フローを分析し、それらをポリシーと比較し、そしてトラフィックを適切に処置する（すなわち、ブロック、許可、速度制限、優先度のタグ、追加分析またはレポーティングのための他のデバイスへのミラー）ために、セキュリティデバイスでますます多く使用されている。ＤＰＩデバイスは、各個々のパケットを探索するため、ユーザ単位ベースでサービスを提供するまたはブロックするためにＩＳＰによって使用されることができる。]
[0007] 前述の本発明の目的および利点は、様々な例示的実施形態によって達成されることができる目的および利点の例示であり、実現されることができる生じ得る利点を網羅するまたは限定するものではない。従って、様々な例示的実施形態のこれらのおよび他の目的および利点は、本明細書の記載から明らかになることになる、あるいは、本明細書のように実施されるまたは当業者に明らかになりうるいずれかの変形形態を考慮して修正される両方の様々な例示的実施形態の実施から知られることができる。従って、本発明は、様々な例示的実施形態で本明細書に示されまた説明される新規の方法、構成、組合せ、および改善に存在する。]
発明が解決しようとする課題

[0008] 残念ながら、その既存の形態において、ＤＰＩおよび関連システムは、アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構を提供することができない。アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構の現在の必要性に照らして、様々な例示的実施形態の要約が提示される。様々な例示的実施形態のいくつかの態様を明らかにし、紹介することを目的として、しかし本発明の範囲を限定することなく、以下の要約ではある種の簡単化および省略が行われることがある。当業者が本発明の概念を行い使用することができるようにするための適切な好ましい例示的実施形態の詳細な説明が後節に続く。]
課題を解決するための手段

[0009] 様々な例示的実施形態が、特にアプリケーションレベルでのトラフィックフローの処置に関して、サービスプロバイダ（ＳＰ）ネットワーク内でルータを効率的に構成する。これは、提供されているアプリケーションレベルのサービスに有益であると考えられている。]
[0010] 現在、この能力は存在しない。顧客レベルでの構成検査は、別個のＤＰＩシステムを使用して可能であるが、これは所望のアプリケーションレベルの細分性を提供せず、データプレーン転送検査を提供しない。従って、様々な例示的実施形態は、所望の量のアプリケーションレベルの細分性をもつ顧客レベルでの構成検査を可能にする。]
[0011] 本明細書に記載の問題を解決するために、様々な例示的実施形態は、新しいタイプのサービスｐｉｎｇパケットを含む。これは、本明細書において、アプリケーションに特化したサービスｐｉｎｇパケットと呼ばれる。]
[0012] このタイプのパケットは、パケットによる、テストされるまたはシミュレートされるアプリケーションの表示を含む。これは、ＤＰＩ機器が１つだけのパケットから問題のアプリケーションを素早く判定することを可能にする。]
[0013] パケットを処理したネットワークルータ内の動的トラフィックポリシーの構成を検査するためのパケットに適用されるかかるポリシーに関する構成を含み、アプリケーションまたはその任意の部分についてどのタイプの構成情報が集められることになるかを指定する任意の関連アプリケーションパラメータが、特に双方向が同一経路を横断していないときに双方向のデータプレーン検証を可能にするために、パケットならびにパケットがその宛先に到達するときそのソースにループバックされることになるかどうかのループバック表示にも含まれることができる。]
[0014] 従って、様々な例示的実施形態で、アプリケーションに特化したサービスｐｉｎｇパケットは、所与のアプリケーションに対し、ある顧客から別の顧客へのトラフィックフローなどの所与のトラフィックフローに対して作成される。アプリケーションに特化したサービスｐｉｎｇパケットは、発信パケットまたはプロバイダエッジ機器インタフェースのソースを含む任意のポイントでネットワークに注入される。アプリケーションに特化したサービスｐｉｎｇパケットは、次に、別のプロバイダエッジ機器インタフェースまたはアプリケーショントラフィックの最終宛先を含むことができる所定の宛先に向かってネットワークを横切って通過する。]
[0015] 様々な例示的実施形態において、アプリケーションに特化したサービスｐｉｎｇパケットがネットワークを横切って通過している間に、それは、そのアプリケーションに特化したサービスｐｉｎｇパケットが通過中にそれに対して適用されるアプリケーション構成／フロー依存のトラフィック処理ポリシーに関する情報を収集する。これらのポリシーは、静的でも動的でもよい。]
[0016] 様々な例示的実施形態で、パケット内に収集される情報は、かかる情報を提供することができるすべてのノードにまたは要求された情報を含むためにパケット内で指定されたノードのみに由来することができる。様々な例示的実施形態で、収集された情報は、ネットワークを通過している間に所与のトラフィックフローが通過したルータの構成を検査するために所与のトラフィックフローに対して期待される結果と比較される。様々な例示的実施形態で、前述の手順の１つまたは複数のステップは、他方のプロバイダエッジ機器インタフェースで始まり、たとえばデータプレーンの連続性チェックを実行するために、別のまたは同一のループバックされたパケットを他方のインタフェースへと反対方向に送って、繰り返される。]
[0017] 様々な例示的実施形態をより深く理解するために、添付の図面が参照される。]
図面の簡単な説明

[0018] アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構の例示的システムの概略図である。
アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のための例示的なアプリケーションに特化したサービスｐｉｎｇパケットの断片化された概略図である。
アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のためのアプリケーションに特化したサービスｐｉｎｇパケットの例示的アプリケーション識別フィールドの概略図である。
アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のシステムおよび方法とともに使用される例示的アプリケーションマッピング表の断片化された概略図である。
アプリケーションアウェアネスを用いて終端間サービス構成を検査する例示的方法の流れ図である。]
実施例

[0019] ここで図を参照すると、同様の番号は同様のコンポーネントまたはステップを指しており、様々な例示的実施形態の広範な態様が開示される。]
[0020] 図１は、アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構の例示的システム１００の概略図である。システム１００内の通信は、ネットワークエレメントＡ、通信ネットワーク１１０、およびネットワークエレメントＢを介して顧客Ａと顧客Ｂの間を進む。] 図１
[0021] ネットワークエレメントＡは、ルータＡおよびＤＰＩ Ａを含む。同様に、ネットワークエレメントＢは、ルータＢおよびＤＰＩ Ｂを含む。但し、様々な例示的実施形態において、ネットワークエレメントＡそれ自体がＤＰＩであることに留意されたい。同様に、様々な例示的実施形態において、ネットワークエレメントＢそれ自体がＤＰＩである。]
[0022] 換言すれば、ネットワークエレメントＡは、それがＤＰＩをもつまたはＤＰＩである限り、任意の可能な形態をとることができる。同じことがネットワークエレメントＢにもあてはまる。同様に、ネットワークエレメントＡおよびネットワークエレメントＢは、ＱｏＳ、ポリシング、パケットのリマーキングなどのアプリケーション処理、およびパケットが通信ネットワーク１１０を横切る経路に影響するＤＳＣＰをもつ。]
[0023] 本明細書に記載の本発明は、２つ以上の任意の数のＤＰＩを含むシステム１００内で機能することにもまた留意されたい。例示的システム１００には、単純化するために、ＤＰＩが２つだけ示されている。それらはＤＰＩ ＡおよびＤＰＩ Ｂである。]
[0024] 例示的システム１００には、ルータＡがネットワークインタフェース（ＮＩ）のＮＩ１およびＮＩ２とともに示されている。同様に、ルータＢがＮＩ３、ＮＩ４とともに示されている。ルータＡおよびルータＢを排除するシステム１００の実施形態では、ＮＩ１、ＮＩ２、ＮＩ３およびＮＩ４が適切に再配置されることは明らかであろう。様々な例示的実施形態で、１つまたは複数のＮＩ１、ＮＩ２、ＮＩ３およびＮＩ４はプロバイダエッジ機器インタフェースである。]
[0025] 様々な例示的実施形態では、複数の顧客が、直接またはブリッジ、スイッチもしくはルータを含むがこれらに限定されない別のネットワークを介して間接的にプロバイダエッジ機器インタフェースＮＩ１およびＮＩ４に接続されることができる。アプリケーショントラフィックは、ポイント対ポイント、ポイント対マルチポイント、マルチポイント対ポイント、またはマルチポイント対マルチポイントの性質のいずれかでもよい。]
[0026] 本発明は、ここで図２−５に関連してさらに詳しく説明される。図２−５に関連して、図１に戻り参照すると、そこに示されたエレメントは、例示的システム１００に関して示された構造の機能および相関関係をさらに広げるために使用される。] 図１ 図２
[0027] 図２は、アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のための例示的アプリケーションに特化したサービスｐｉｎｇパケット２００の断片化された概略図である。例示的ｐｉｎｇパケット２００は、標準ＤＰＩフローＩＤ２１０、特殊ｐｉｎｇパケットＩＤ２１５、ＤＰＩ特殊パケットＩＤ２２０、およびアプリケーションＩＤ２３０を含む。いくつかの実施形態で、ＤＰＩ特殊パケットＩＤ２２０は必要とされないことがあり、特殊ｐｉｎｇパケットＩＤ２１５とアプリケーションＩＤ２３０の組合せで十分となりうる。] 図２
[0028] ＤＰＩ特殊パケットＩＤ２２０およびアプリケーションＩＤ２３０は、他の知られている形態のｐｉｎｇパケットに以前には含まれていないｐｉｎｇパケット２００の部分である。標準ＤＰＩフローＩＤ２１０は、特定のフローを識別するためにＤＰＩによって通常は要求される情報を表す。標準ＤＰＩフローＩＤ２１０に先行する例示的パケット２００の内容は、図２では単純化するために省略されている。これは、図２の断片化された部分によって表される。] 図２
[0029] ＤＰＩ特殊パケットＩＤ２２０は、例示的アプリケーションに特化したサービスｐｉｎｇパケット２００内の標準ＤＰＩフローＩＤ２１０および特殊ｐｉｎｇパケットＩＤ２１５の後ろにある。ＤＰＩ特殊パケットＩＤ２２０は、ＤＰＩ ＡまたはＤＰＩ ＢなどのＤＰＩが、そのアプリケーションに特化したサービスｐｉｎｇパケット２００がこの特定のまたは任意のＤＰＩエレメントによって処理されることになる特殊な種類のＤＰＩパケットであることを認識できるようにする例示的なアプリケーションに特化したサービスｐｉｎｇパケット２００内の情報を表す。いくつかの実施形態で、パケットを処理するためのＤＰＩの識別は、ＤＰＩ特殊パケットＩＤの部分ではなくそのかわりに標準ＤＰＩフローＩＤ２１０またはアプリケーションＩＤ２３０または特殊ｐｉｎｇパケットＩＤ２１５のようなパケット内の他の任意のフィールドの部分であることがある。この情報は、当技術分野で現在知られているまたは後から開発されるいずれかの技法に従って実装されることができる。]
[0030] アプリケーションＩＤ２３０は、パケットをそれが所定のアプリケーションに属するかのように分類するアプリケーションに特化したデータを表す。但し、ＤＰＩ特殊パケットＩＤ２２０または特殊ｐｉｎｇパケットＩＤ２１５（特殊パケットＩＤ２２０が必要でないとき）のために、例示的なアプリケーションに特化したサービスｐｉｎｇパケット２００は、単一パケットのみを使用して識別されたアプリケーションをＤＰＩに関連付けることができる。このことは、アプリケーションを識別するための既に知られているすべての技法では関連アプリケーションが識別されることができる前に複数のパケットの検査を必要とするため、かかる技法に対する顕著な改善を表す。]
[0031] 図３は、アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のためのアプリケーションに特化したサービスｐｉｎｇパケットの例示的アプリケーション識別フィールド２３０の概略図である。例示的アプリケーション識別フィールド２３０は、タイプフィールド２３３、長さフィールド２３６および値フィールド２３９を含む。] 図３
[0032] 様々な例示的実施形態で、タイプフィールド２３３は、識別されたアプリケーションが属するアプリケーションタイプを識別するのに使用される。様々な例示的実施形態で、長さフィールド２３６は関連する長さを識別する。]
[0033] 様々な例示的実施形態で、値フィールド２３９は、例示的アプリケーションＩＤフィールド２３０によって識別されるアプリケーションに関する情報の値を含む。値フィールド２３９の内容の例は、アプリケーションコードポイントおよびアプリケーションデータポイントを含む。様々な例示的実施形態で、アプリケーションＩＤフィールド２３０は、２つ以上のタイプ長さ値（ＴＬＶ）フィールドを運ぶ。従って、様々な例示的実施形態で、アプリケーションＩＤフィールド２３０は、ＤＰＩによるアプリケーション識別および処理を定義するネストされたＴＬＶフィールドを含む。同様に、様々な例示的実施形態で、アプリケーションＩＤフィールド２３０は、たとえば複数のアプリケーション、単一アプリケーションの複数のサブセット、またはそれらの組合せに対応する複数のアプリケーションＩＤを含む。様々な例示的実施形態で、アプリケーションＩＤフィールド２３０内の情報が、現在知られているまたは後から開発されるＴＬＶ以外の任意のフォーマットに従って符号化されることもまた明らかであろう。]
[0034] 図４は、アプリケーションアウェアネスを用いて終端間サービス構成を検査するインバウンド機構のシステムおよび方法とともに使用するための例示的アプリケーションマッピング表４００の断片化された概略図である。マッピング表４００は２つの列を含む。第１の列には、アプリケーションＩＤのラベルが付けられている。第２の列には、アプリケーション名のラベルが付けられている。] 図４
[0035] 図示するように、アプリケーションマッピング表４００は、３行のデータを含む。第１の行は、アプリケーションＩＤ１をもつ。第２の行はアプリケーションＩＤ２をもつ。第３の行はアプリケーションＩＤ３をもつ。示されたアプリケーションＩＤが非常に単純なものであることは明らかであろう。従って、任意の値または文字列がアプリケーションＩＤ列のアプリケーションに対応するのに使用されることができることは同様に明らかであろう。]
[0036] アプリケーションマッピング表４００では、アプリケーション名のフィールドは空欄にされている。しかし、マッピング表４００の実際の実装が表４００の各行の対応するアプリケーションＩＤのそれぞれに対応するアプリケーション名列に名前を含むことになろうことは明らかであろう。]
[0037] アプリケーションマッピング表４００は、任意の数のアプリケーションＩＤがアプリケーションマッピング表４００に含まれうることを表すために断片化されている。アプリケーションマッピング表４００の使用は、図５に関して以下にさらに詳しく説明される。] 図５
[0038] 図５は、アプリケーションアウェアネスを用いて終端間サービス構成を検査する例示的方法５００の流れ図である。方法５００は、ステップ５０５で始まり、ステップ５１５に続く。] 図５
[0039] ステップ５１５で、ヘッダアプリケーション情報（ｉｎｆｏ）をもつサービスｐｉｎｇパケットが構築される、すなわち形成される。様々な例示的実施形態で、ステップ５１５のサービスｐｉｎｇパケットは、少なくとも図２および図３に関して前述された、アプリケーションに特化したサービスｐｉｎｇパケット２００に対応する。] 図２ 図３
[0040] ステップ５２５で、ステップ５１５で構築されたサービスｐｉｎｇパケットが、システム１００内の宛先へと転送される。様々な例示的実施形態で、これは顧客Ａのネットワークに注入される、すなわちロードされるサービスｐｉｎｇパケット、または、ＮＩ１、ＮＩ２、ＮＩ３、ＮＩ４などのネットワークインタフェースを含む顧客Ｂへの通信経路に沿った任意のインタフェースを含む。次に、ステップ５３０で、アプリケーションに特化した処理が実行されるかどうかの判定が行われる。]
[0041] アプリケーションに特化した処理が行われないという判定がステップ５３０で行われるとき、方法５００はステップ５２５に戻り、そこでサービスｐｉｎｇパケットは宛先へと転送され続ける。アプリケーションに特化した処理が行われるという判定がステップ５３０で行われるとき、方法５００はステップ５３５に進む。次にステップ５３５で、ネットワークエレメントＡのＮＩ１、ＮＩ２またはネットワークエレメントＢのＮＩ３、ＮＩ４などのネットワークエレメントの１つまたは複数のネットワークインタフェースで静的アプリケーション構成情報が判定される。]
[0042] ステップ５４５で、ステップ５３５で判定された静的アプリケーション構成情報が、サービスｐｉｎｇパケットに挿入される。ステップ５５５で、フローに適用されることになるポリシーが判定される。様々な例示的実施形態で、ステップ５５５で判定される１つまたは複数のポリシーは、ポリシールックアップテーブルから判定される。次にステップ５６５で、ステップ５５５で判定されたポリシーがサービスｐｉｎｇパケットに挿入される。]
[0043] 所与のフローに影響を及ぼすポリシーの一例は、フローの時間に対するフローの量であろう。たとえば、所与のシステムは、ネットワークを介する他のトラフィックが概して少ない深夜の特定のフローに対してはより多くの量を許すことができる。１つまたは複数のポリシーの判定およびそのサービスｐｉｎｇパケットへの挿入は、本明細書で説明する動的構成情報に相当する。]
[0044] ステップ５７０で、ｐｉｎｇパケットの宛先が到達されたかどうかの判定が行われる。宛先が到達されていないという判定がステップ５７０で行われるとき、方法５００はステップ５２５に戻り、サービスｐｉｎｇパケットはｐｉｎｇ宛先へと転送され続ける。宛先が到達されたという判定がステップ５７０で行われたとき、方法５００はステップ５７５に進む。]
[0045] ステップ５７５で、サービスｐｉｎｇパケットが、ネットワークから抽出される。単純化するために、ステップ５７５はステップ５７０の後にのみ示されている。しかし、様々な例示的実施形態で、サービスｐｉｎｇパケットが、先行するステップのうちのいずれか１つまたは複数に続いてネットワークから抽出されることは明らかであろう。ステップ５７５の後、方法５００はステップ５９５に進み、方法５００は終了する。]
[0046] 様々な例示的実施形態がそのある種の例示的な態様を具体的に参照して詳述されているが、本発明では他の実施形態も可能であり、また、その詳細は様々な明白な点で修正が可能であることを理解されたい。当業者には容易に明らかであるように、本発明の趣旨および範囲内に留まりつつ変形形態および修正形態が実施され得る。従って、前述の開示、説明および図は、説明を目的とするものにすぎず、特許請求の範囲によってのみ定義される本発明を決して限定しない。]

权利要求:

請求項1
アプリケーションアウェアネスを用いて終端間サービス構成を検査する方法であって、アプリケーションに特化したサービスｐｉｎｇパケットが対応するアプリケーションを識別するアプリケーション識別フィールドをもつそのアプリケーションに特化したサービスｐｉｎｇパケットを構築するステップと、そのアプリケーションに特化したサービスｐｉｎｇパケットをネットワーク内の宛先へと転送するステップと、ネットワークエレメントのネットワークインタフェースでそのアプリケーションに特化したサービスｐｉｎｇパケットが対応するアプリケーションに関する静的構成情報を判定するステップと、その静的構成情報をそのアプリケーションに特化したサービスｐｉｎｇパケットに挿入するステップと、そのアプリケーションに特化したサービスｐｉｎｇパケットを含むフローに適用する少なくとも１つのポリシーを判定するステップと、その少なくとも１つのポリシーをそのアプリケーションに特化したサービスｐｉｎｇパケットに挿入するステップと、ネットワークからそのサービスｐｉｎｇパケットを抽出するステップとを含む、方法。
請求項2
そのネットワークからサービスｐｉｎｇパケットを抽出するステップが、構築、転送、判定、収集、および挿入のステップのうちの少なくとも１つに続いて生じる、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項3
ネットワークインタフェースでネットワークにアプリケーションに特化したサービスピングパケットを注入するステップをさらに含む、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項4
宛先ノードが到達されたかを判定するステップと、そして、その宛先ノードが到達されていなかった場合に、転送、判定、収集、および挿入のステップを繰り返すステップとをさらに含む、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項5
静的構成情報を期待される結果と比較するステップと、ネットワーク内の１つまたは複数のルータの構成を比較によって検査するステップとをさらに含み、そのアプリケーションに特化したサービスｐｉｎｇパケットがネットワーク内の１つまたは複数のルータを通過した、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項6
どのタイプの情報がアプリケーションに特化したサービスｐｉｎｇパケットに含まれることになるかを指定するステップをさらに含み、アプリケーションに特化したサービスｐｉｎｇパケットに含まれることになるその情報のタイプが、静的情報のサブセット、動的情報のサブセット、および静的および動的両方の情報のサブセットから成る群から任意で選択される、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項7
そのアプリケーションに特化したサービスｐｉｎｇパケットを顧客インタフェースでネットワークに注入するステップをさらに含む、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項8
アプリケーションに特化したサービスｐｉｎｇパケットがネットワーク内の所定のポイントで抽出されるか、またはネットワーク内の所定のポイントでループバックされる、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項9
通信経路に沿いアプリケーションに特化したサービスｐｉｎｇパケットを処理するためにネットワーク内のＤＰＩエレメントの特定のサブセットを使用するステップをさらに含む、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。
請求項10
アプリケーションに特化したサービスｐｉｎｇパケットを処理することになるネットワーク内のノードのＩＤを含むことによって、そのアプリケーションに特化したサービスｐｉｎｇパケットを処理することになるネットワーク内のノードのサブセットを指定するためにそのアプリケーションに特化したサービスｐｉｎｇパケットを使用するステップをさらに含み、アプリケーションに特化したサービスｐｉｎｇパケットを処理することになるネットワーク内のノードのそのＩＤが任意で、ｐｉｎｇ宛先、アプリケーションＩＤ、および特殊パケットＩＤから成るリストから選択されるそのアプリケーションに特化したサービスｐｉｎｇパケット内のフィールドの部分である、請求項１に記載のアプリケーションアウェアネスを用いて終端間サービス構成を検査する方法。